home *** CD-ROM | disk | FTP | other *** search
/ Alles Voor Internet / Tout Pour Internet / alles voor internet.iso / MacInternet™ / Archive-tools / suntar 2.0.2 Folder / speed tests < prev    next >
Text File  |  1994-07-02  |  8KB  |  203 lines
  1.  
  2. Times (in seconds) on a Macintosh LC with 40MB hard drive (access time 26 msec)
  3. When not specifed, the times are with almost all INITs disabled
  4. (there where only a couple which load themselves before the INIT manager
  5. and SuperClock, which was used to measure speeds by subtracting the
  6. initial and final times)
  7.  
  8. ••••un-BinHex (ram disk -> hard disk, 900k file)
  9.  
  10. ZipIt: an error message and the extraction failed
  11. suntar 1.1 (.hqx.tar)  210 sec    (the slowest unBinHexer in the world...)
  12. deHQX 2.0                 150 sec  (ram-ram) 175 sec (HD->HD) 
  13. Stuffit 1.5.1        146 sec
  14. suntar 1.2.1         137 sec            (I carefully optimized the algorithm, but unfortunately
  15.                                 that was not the bottleneck)
  16. Stuffit Deluxe 3    125 sec
  17. Downline    1.1     125 sec
  18. BinHex 4.0              90 sec
  19. Compact Pro 1.3.3    49 sec (with or without INITs: no event handling, no background
  20.                             operation, the Macintosh does nothing else until the extraction
  21.                             finished: I never liked this way to speed up an application)
  22. suntar 1.3.3        43 sec (48 with INITs)    (introduced disk buffering, and the
  23.                         optimizations introduced in 1.2 may now show their strength)
  24. BinHqx DA (32k buffer size)        36 sec (38 with INITs)
  25. suntar 2.0            33 sec    (36 with INITs)       (uses a look-up table to compute the
  26.                                         CRC error checking: pole position !!!)
  27.                                 
  28. ••••compressed PackIt extraction (ram disk -> hard disk, 900k file)
  29.  
  30. Downline: an error message and the extraction failed
  31. PackIt III                    315 sec (320 sec with INITs)
  32. suntar 1.2.1      156 sec  (175 sec with INITs)
  33. Stuffit Deluxe 3  130 sec
  34. Stuffit 1.5.1        120 sec
  35. unpit 0.1                    105 sec
  36. unpit 0.3 (compiled with Think C 5, I had the source but could not find the application)
  37.                   100 sec
  38. suntar 1.3.3      88 sec        (no change to the algorithm, but benefits from I/O buffering)
  39. suntar 2.0 beta 8   66 sec    (uhh, in suntar 1.3 I'd forgotten to fully enable buffering !
  40.                             And obviously the faster CRC routine helps)
  41. suntar 2.0        42 sec    (optimized the routine: it's not nice being
  42.                             proud of something which I knew was not the
  43.                             best I could do)
  44.  
  45. ••••non-compressed PackIt extraction (ram disk -> hard disk, 900k file)
  46.  
  47. PackIt III             225 sec
  48. suntar 1.2.1   100 sec
  49. StuffIt 1.5.1   65 sec
  50. StuffIt Deluxe 65 sec
  51. suntar 1.3.3    40 sec
  52. unpit 0.1                29 sec
  53. unpit 0.3                28 sec
  54. Downline       23 sec
  55. suntar 2.0 b8  18 sec       (the gain from 1.3.3 to 2.0 b8 is 22 sec: same file, same gain)
  56. suntar 2.0     12 sec
  57.  
  58. ••••tar extraction (floppy disk->ram disk, a directory with many files,
  59.     end of archive at sector 2556)
  60.  
  61. suntar 1.1      140 sec  (187 with INITs)
  62. suntar 1.2.1   140 sec  (185)
  63. StuffIt Deluxe (.tar file on a HFS floppy)  75 sec (+16 for reading
  64.     the directory + the time to select all the files in the scrolling list)
  65. tar 3.0                51 sec     (59)
  66. suntar 2.0   51 sec     (58)        (the accuracy of measurements can't guarantee a
  67.                                     1 sec difference but suntar 2.0 performs some tests
  68.                                     to identify long pathnames and it is reasonable
  69.                                     to expect a small speed decrement over 1.3.3)
  70. suntar 1.3.3 50 sec        (56)
  71.  
  72. (suntar 2.0: save sectors 0 to 2556 36 sec, Copy disk archive to file 47 sec)
  73.  
  74. ••••tar extraction (file on hard disk->ram disk, 2556 sectors archive)
  75.  
  76. suntar 1.1   96 sec   (138 sec with INITs)
  77. suntar 1.2.1 92 sec      (135 sec)
  78. StuffIt Deluxe 3.0.6   30 sec (33 with INITs) (+5 to read the directory)
  79. suntar 1.3.3 22 sec        (28)
  80. suntar 2.0   22 sec     (27)
  81. tar 3.0      18 sec     (21)
  82.  
  83. ••••tar extraction (HD->HD, 900k file)
  84.  
  85. suntar 1.1       92 sec
  86. suntar 1.2.1    90 sec
  87. untar 1.0         60 sec    (it's a new program and I did not perform other tests on it)
  88. StuffIt Deluxe  21 sec
  89. suntar 1.3.3    17 sec
  90. suntar 2.0      17 sec
  91. tar 3.0         12 sec
  92.  
  93. ••••uudecode (ram disk -> hard disk, 900k file)
  94.  
  95. uulite 1.3                    300 sec    (what a pity, its user interface is very good, but so slow…)
  96. UMCP™ Tools        95 sec
  97. tiger             65 sec (ram->ram)  120 sec (HD->HD)
  98. un*files (bug fixed and recompiled with ThC 4)   55 sec (ram->ram) 105 sec (HD->HD)
  99. StuffIt Deluxe   46 sec
  100. suntar 2.0         29 sec
  101. uuparse                        23 sec
  102. uutool 2.32       20 sec
  103.  
  104. ••••Macbinary extraction (HD->HD, 900k file)
  105.  
  106. UMCP™ Tools    100 sec
  107. suntar 1.2.1        96 sec
  108. BinHex 5.0      29 sec
  109. StuffIt Deluxe  24 sec
  110. MacBinary II+   17 sec
  111. suntar 1.3.3    17 sec
  112. suntar 2.0      17 sec
  113. suntar 2.0 (with double-sized buffers) 14 sec
  114. MacBinary 1.01  12 sec
  115. ZipIt            7 sec (but in a different configuration, also suntar was
  116.                     a couple of seconds faster that day. Since ZipIt is a big program,
  117.                     probably it uses a huge buffer)
  118.  
  119. ••••tar creation (HD->ram disk, 700k directory)
  120.  
  121. StuffIt Deluxe  28 sec
  122. suntar 2.0      24 sec
  123. tar 3.0         21 sec
  124.  
  125. ••••tar creation (HD->HD, 900k file)
  126.  
  127. StuffIt Deluxe  17 sec
  128. suntar 2.0      16 sec
  129. tar 3.0         12 sec
  130.  
  131. ••••tar creation (HD->floppy disk, 700k directory)
  132.  
  133. suntar 1.1     400 sec
  134. suntar 1.2.1   360 sec
  135. StuffIt Deluxe  (file on a Mac floppy disk) 125 sec
  136. tar 3.0        49 sec
  137. suntar 1.3.3   45 sec        (buffered only towards the floppy)
  138. suntar 2.0     42 sec
  139.  
  140. ••••BinHex creation (HD->ram, 900k file)
  141.  
  142. StuffIt 1.5.1  128 sec
  143. StuffIt Deluxe 110 sec
  144. Downline       95 sec
  145. BinHex 4.0     92 sec
  146. BinHqx DA      51 sec
  147. Compact Pro    47 sec
  148. suntar 2.0      29 sec
  149.  
  150. ••••MacBinary creation (HD->HD, 900k file)
  151.  
  152. UMCP™ Tools     100 sec
  153. suntar 2.0 b8   35 sec                (buffered towards the destination but not the source)
  154. BinHex 5.0      29 sec
  155. StuffIt Deluxe  26 sec
  156. MacBinary II+   17 sec
  157. suntar 2.0      15 sec
  158. MacBinary 1.01  13 sec
  159.  
  160. If you are a programmer and you want to write fast code, this is what
  161. I learnt in the process of speeding up suntar:
  162.  
  163. 1) I/O buffering is always essential: I believe that in many categories
  164.    the faster is the program which uses the largest buffer. The large
  165.    jumps in the times (e.g. a factor of 2) between two programs are always
  166.    due to different buffering schemes (e.g.: read one char at a time,
  167.    512 bytes, 8k or more). But there is a point at which increasing the
  168.    buffer gets no increase in speed, which depends on the device: for a
  169.    hard disk 8k is good,  for a floppy disk it's better 9k (that's a
  170.    track or half track on 720k or 1440k floppy disks), and very large
  171.    buffers are still useful for an extraction to the same device if
  172.    the source file and the destination file are placed at different
  173.    positions and a large head movement is required every time the
  174.    application loads or flushes a buffer.
  175. 2) only for complex conversions, at least for operations on fast disks,
  176.    it's important a well optimazed algorithm, where most operations
  177.    are done inside a single loop within a single function, with all
  178.    essential variables kept in registers.
  179. 3) for very simple formats (MacBinary, non-compressed PackIt, tar)
  180.    it's important to handle one format only: suntar suffers from its
  181.    number of supported formats, StuffIt Deluxe suffers even more
  182.    (I mean that it's possible and easy to be 50% faster than suntar
  183.    in uncompressed PackIt extraction, no program does that only
  184.    because the PackIt format is obsolete and the original
  185.    PackIt is outperformed anyway also by non-optimized programs).
  186. 4) only if the algorithm should contain some code written by a
  187.    Mathematician, some knowledge of Mathematics is not bad
  188.    (Mathematicians usually write straighforwardly and never worry
  189.    about speed, but in order to rewrite their code you must understand
  190.    what they're doing).
  191. 5) assembly language is useful, but only in special cases: e.g. mcopy
  192.    is three times faster than a standard memcpy, but it would be almost
  193.    as fast written in C: it's the smart algorithm which makes it fast.
  194.    Assembly language is really essential only if you need instructions
  195.    which the C compiler does not exploit (DBRA, SWAP, BTST, all the
  196.    operations involving the processor flags) or exceptionally when you
  197.    need more register variables than the compiler supports.
  198. 6) never forget to measure the speed and compare it to other programs:
  199.    one may believe to have written a wonderfully fast program and then
  200.    discover that a small detail makes it slow.
  201.  
  202.                             17 October 1993
  203.                             Gabriele Speranza